Design verification is a common process for testing a newly designed integrated circuit, board, or system-level architecture, to, for example, confirm that it complies with the requirements defined by the specification of the architecture for that device. Design verification for a device under test (DUT) may be performed on the actual device, but can usually be a simulation model of the device is tested.
Verification of electronic designs typically has three forms. At an early stage, before the electronic design is implemented in hardware, simulation can be conducted on a model of the design. Another form can be emulation, in which one electronic hardware is used to mimic the behavior of another (tested) electronic hardware. At more advanced stages of design development a system on chip can be validated, in a process which is typically referred to as post-silicon verification. Post-silicon verification can be a last stage in the electronic design development, for example, before it is manufactured.
Post-silicon verification tests can be carried out on actual devices running at speed on realistic system boards, the results of which can be assessed by a logic analyzer and other verification tools.
In a typical verification process an electronic design undergoes testing which includes designing various validated testing scenarios which are generated as code and executed.
Verification tests typically include a plurality of actions that are to be executed, in order to test the validity of the DUT planned design.
Current post-process debugging methods include a method which involves recording a specific program execution and allowing an on-line or off-line analysis of that execution. In this method, when recording the execution, typically all execution events that occurred in are saved.
An “execution event”, typically refers to any event that has occurred during the execution of the program, and may include, for example, a code line that was executed, a routine that was called, a parameter that was calculated, a variable that has been assigned a value, a status of a computing environment, an indication (e.g., text, line, or location within a source code representation or other representation of the software program being debugged, a function currently being executed, an instruction that called the function being currently executed, or other indication) of an instruction that is being executed or that was most recently executed, an address of a variable or instruction, or other relevant information that may be displayed or otherwise made available to a user of the debugging tool, etc.
Information relating to the execution events encountered during an execution can be saved (e.g., into a database, memory, etc.), allowing the review of the recorded execution in a user interface while mimicking the look and feel of a regular debugging tool. Thus, the human user (hereinafter—user) can go back and forth (up to the last execution event that was recorded) and view various execution events of that specific execution, including the related information of these events. Using such a post-process debug method can allow the user to analyze any execution event and/or find the execution events that caused it to occur the way it did.
A post process debugger typically records information relating to a specific execution of a program under test and is designed to utilize that information so as to mimic a look and feel of a “regular” debugger. Using the saved information, the post process debugger may show all the instances in which a given code line was executed, and what were the values of the variables, parameters and/or other fields found in a code line or in the scope of that code line for each instance. The post process debugger may also record all the messages that were printed while running the program, and may have a specially designated graphical user interface (GUI) that presents these messages and allows filtering them in one or various ways.